---
title: "01-网络：从 hosts 文件到内网 WiFi，一次讲透"
created: 2026-07-03
tags:
  - 项目筑基
---
# 网络：从 hosts 文件到内网 WiFi，一次讲透

> 把"一个网址是怎么变成一次实际访问"这件事从头到尾拆开看一遍。
>
> 如果把整个网络世界想象成一座巨大的城市，事情会清晰很多。

### **域名和 IP 地址：门牌名 vs 真实坐标**

你在浏览器里输入的 [www.taobao.com](https://www.taobao.com) 或者 `cnp`，其实就像你对出租车司机说"带我去人民广场"。但司机的导航系统（也就是网络设备）其实根本不认识"人民广场"这四个字，它只认识经纬度坐标，比如"东经121.4737，北纬31.2304"。IP 地址（比如 `10.217.195.81`）就是这个真实坐标，而域名只是我们人类为了方便记忆起的"门牌名"。整个网络世界的核心工作之一，就是把这些好记的门牌名，翻译成机器能用的坐标——这个翻译过程就叫**域名解析**。

### **hosts 文件：贴在自己书桌上的私人电话本**

在正式打电话给"114查号台"（也就是公共 DNS）之前，很多人会先看一眼自己书桌上贴的小纸条，上面手写着几个常用联系人的电话，比如"老王：138xxxx"。这张纸条就是 hosts 文件——它是**你自己电脑本地的、优先级最高的私人地址本**。系统解析域名时，第一件事永远是先翻这张纸条，如果纸条上写了，就直接照着用，压根不会再去问查号台。这就是为什么之前那份hosts文件里，开发者能把 `mrjobs3.com` 这种正式域名强行指向 `127.0.0.1`（也就是"我自己"这个地址）——相当于在纸条上写"以后凡是找老王，其实是找我自己"，用来骗过自己的电脑，方便本地调试。

不过这张纸条有个前提：**上面必须手写过这个名字才有用**。像 `cnp` 这种没有在任何人的私人纸条上出现过的名字，就完全不归 hosts 文件管了，只能去问查号台。

### **DNS：整座城市共享的查号台系统**

如果私人纸条上没写，下一步就要打电话给"114查号台"，这就是 DNS（域名系统）。但有意思的是，城市里并不是只有一个查号台，而是分了"对外营业的市级查号台"和"只服务本单位内部员工的单位内线查号台"。

你家里的宽带、手机流量走的是**公网 DNS**，相当于市级查号台，它只登记那些正规注册、对全世界公开的门牌名（比如 `.com` `.cn` 结尾的正式域名），你问它"帮我查一下'老王'"，它会说"我们查号台没有叫这个的，你是不是打错了"——因为 `cnp` 这种既没后缀、又没在公网注册的名字，根本不在它的登记册里。

而你连进公司 WiFi 后，你的电脑被自动分配去问的是**单位内线查号台**（内网 DNS），这个查号台上登记着只有本单位员工才需要知道的"分机号"，比如把 `cnp` 自动补全成 `cnp.corp.local` 之类的内部全名去查，然后查到一个只在单位内部有效的门牌号。这就是为什么同一个名字，两个查号台给出完全不同结果，甚至一个查得到、一个查不到。

下面这张图能帮你直观看到一次域名解析请求实际走过的路径：

```mermaid
flowchart TD
    A["用户输入域名<br/>比如 cnp 或 mrjobs3.com"] --> B{"本机 hosts<br/>私人电话本里<br/>有没有记录？"}
    B -->|有记录| C["直接按 hosts 里写的<br/>IP 地址访问"]
    B -->|没有记录| D{"当前连的网络<br/>分配的是哪个 DNS？"}
    D -->|内网 WiFi/网线| E["问内网 DNS<br/>单位内线查号台"]
    D -->|家庭宽带/手机流量| F["问公网 DNS<br/>市级查号台"]
    E -->|查到内部私有记录| G["返回私有 IP<br/>如 10.x.x.x"]
    E -->|查不到| H["解析失败"]
    F -->|查到公开注册记录| I["返回公网 IP"]
    F -->|查不到/域名不存在| H
    G --> J{"这个 IP 是否<br/>在物理上可达？"}
    J -->|设备已接入该内网| K["访问成功"]
    J -->|设备在外网、未接入| L["无法路由，访问失败"]
```

### **私有 IP 地址：小区内部门牌号，出了小区就不认**

前面测出来的 `10.217.195.81` 属于一类特殊的门牌号——它就像"3号楼2单元501室"这种门牌，这套编号系统**只在小区内部有效**，出了小区大门，全世界任何一个快递员都不知道"3号楼"到底在哪个城市。互联网协议特意留了三段号码专门用来当这种"小区内部门牌"，任何公网设备都不会分配到这些号码，也不会去尝试给它们导航：

| 私有地址段 | 常见比喻 | 典型使用场景 |
| --- | --- | --- |
| `10.0.0.0 ~ 10.255.255.255` | 大型社区的门牌 | 大公司、大园区，设备数量多 |
| `172.16.0.0 ~ 172.31.255.255` | 中型小区的门牌 | 中等规模企业网络 |
| `192.168.0.0 ~ 192.168.255.255` | 单栋小楼的门牌 | 家庭路由器、小型办公室 |

你的电脑拿到 `10.217.195.81` 这个号，就相当于领到了一张"XX大厦内部通行证"，这张证在大厦里到处好使，但你拿着它走到大厦外面的马路上，是没有任何意义的——这也解释了为什么哪怕外网电脑手动配了同样的域名解析，最终指向的还是这样一个私有 IP，也照样进不去,因为公网的路由体系压根不知道要把包送到哪个"大厦"去。

### **子网掩码：小区被分成了几个门栋，各自管各自**

`255.255.255.128` 这个掩码，作用类似小区物业在门牌号规则上做的一个补充说明："3号楼下面又细分成了A栋和B栋，A栋只能容纳126间房"。掩码决定了从这一整段号码里，切出多大一块算作"同一个门栋"（同一个子网），门栋内部的住户互相串门非常方便（可以直接找到彼此），但如果要去别的门栋，就必须经过门栋出入口的保安登记——这个"出入口保安"就是下一个要讲的网关。

### **网关：这栋楼唯一对外的大门保安**

`10.217.195.1` 这个地址,几乎总是取整个子网里的第一个号,原因就跟现实中"物业办公室通常设在1号门"一样,是约定俗成的习惯。它的角色是——你人在楼里，想寄一封信到楼外(不管是寄到公司别的楼栋，还是寄到国外)，都不能自己直接扔出去，必须先交给这栋楼门口的保安/前台(网关)，由保安负责往下一级(可能是另一个更大的枢纽，最终连到运营商的互联网出口)转交。整栋楼、整个小区所有人的"对外信件"，都先汇总到这一个大门，这也是为什么企业网络里网关地址往往很关键、监控和限速也常常在这里做文章。

### **DHCP：入住时自动帮你分配门牌号和保安电话**

你连上公司 WiFi 时，其实完全没有手动填过任何 IP 地址,这背后是**DHCP**在悄悄工作，它就像小区入住时物业前台自动给你的"入住礼包"：一张门牌号(IP 地址)、一张写着"有事找1号门保安"的纸条(默认网关)，以及一本"内部查号台电话本怎么打"的说明书(DNS 服务器地址,有时还包括内部域名后缀)。整个过程你毫无感觉，插上网线或连上 WiFi 那一刻，这份礼包就自动到手了。

### **端口号：进了小区还要找对窗口**

门牌号(IP)只负责把你带到**这台机器**跟前,可一台机器上同时跑着一堆程序——网页服务、数据库、你自己写的编译器后端……操作系统怎么知道一包数据是递给哪个程序的？靠的就是**端口号**。它相当于门栋里的一排服务窗口:1 号窗口办什么、2 号窗口办什么,是各程序提前"占好"的。你平时写的 `127.0.0.1:8080`,冒号后面的 `8080` 就是在说"找我自己这台机器的 8080 号窗口"。窗口编号 0~65535,其中 0~1023 是各机构预留的"官方窗口"(80=网页、443=HTTPS、22=SSH、3306=MySQL、5432=PostgreSQL、6379=Redis),1024 以上留给普通程序随便登记,`8080` 就是最常见的"临时窗口"。浏览器里不写端口也能访问,是因为它默认帮你补了 80/443——就像有些机构你报名字人家就知道去几号窗口。所以一次完整的访问链路其实是:**域名翻译成 IP(找到小区)→ 端口(找到窗口)→ 进程(窗口后面的办事员)**。

### **VPN：给外地人办的一张"虚拟通行证"，让他隔空"住进"小区**

最后回到 VPN 这个概念。如果你人根本不在这栋楼里(比如在家、在咖啡厅)，却又想用内部通行证进出内部设施，VPN 干的事情就是：**在你和这栋楼之间架一条加密的秘密通道**，你的电脑通过这条通道"隔空"领到一张跟真的坐在楼里一样的门牌号和内部电话本权限，对楼里的保安系统来说，你看起来就跟真的坐在工位上一模一样。而你现在的情况恰恰是——人真的坐在楼里、真的连上了楼里的 WiFi，天然已经是"住户"身份，压根不需要再办这张虚拟通行证，这也是为什么没装 VPN 却照样能访问内部系统的根本原因。

### **现场验证的小工具：眼见为实**

上面这套逻辑听起来顺,真遇到问题时怎么一层层验证？三个最常用的小命令（Windows 下为例）:

| 命令 | 对应比喻 | 干什么用 |
| --- | --- | --- |
| `ipconfig /all` | 拆开物业的"入住礼包"看内容 | 本机 IP、网关、DNS 服务器一目了然,连的是哪个网、礼包发没发对,一眼定 |
| `ping 10.217.195.1` | 冲着保安喊一嗓子,听有没有回音 | 测"物理上通不通"——IP 能 ping 通但域名打不开,问题多半出在解析;ping 都不通,是接入层的事 |
| `nslookup cnp` | 绕过自己的书桌,直接打电话问查号台 | 看这个域名到底被翻译成了什么 IP,用来区分"解析错了"还是"解析对了但机器进不去" |

顺带把那张"私人电话本"的真身交代一下——hosts 文件就躺在这两个位置（改完要清一下系统的解析缓存才立刻生效）:

| 系统 | 文件位置 | 改完生效 |
| --- | --- | --- |
| Windows | `C:\Windows\System32\drivers\etc\hosts`（记事本以管理员身份打开） | `ipconfig /flushdns` |
| macOS / Linux | `/etc/hosts` | 一般立即生效,必要时重启浏览器 |

之前提到的"把 `mrjobs3.com` 强行指向 `127.0.0.1`"就是往这个文件里加一行 `127.0.0.1 mrjobs3.com`——纸条上手写一条,自己的电脑就永远先信它。

这几个概念其实是层层嵌套的关系：**先有物理接入(连上内网 WiFi)，才有网络身份(DHCP 分配的私有 IP、网关、DNS)，才有域名解析能力(内网 DNS 能查到私有域名)，最终才落地成一次成功的访问**。反过来，任何一环缺失——不在物理内网、没有 VPN 桥接、DNS 用的是公网查号台——都会在某一步卡住，这正是你这几轮遇到的现象背后统一的底层逻辑。

---
🏠 [[00-网络与项目|00-网络与项目]] ➡️ [[02-网络知识探索 - 从好奇心驱动到系统认知|网络知识探索]]